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A draft white paper overview of WSTs proposed NOS, to be used for 
internal project definition and as an initial draft for patent applications. 



WST is developing a telecommunications system with two key but distinct components: wireless connectivity and 
an open software architecture. This document focuses on the software, but includes brief descriptions of relevant 
hardware issues. 

The two components combine to make a system that gives service providers access to end users (the wireless link) 
and a platform (the open OS) for developing a wide range of specialized voice and data services. Physically, the 
system consists of a collection of "patchpoints** in the end-user's homes or businesses, connected to a network of 
basestations through a third-generation (data-capable) cell-phone link. The patchpoints support voice (through RJ- 
1 1 jacks) and data (through an Ethernet connection). 

The system is data-centric in that it uses a very general model of telecommunications, with voice services as a par- 
ticular case, but voice is a key "use case" for which good performance is a must. 

We are defining an applications prograrnrning interface (API) which will permit third-party developers to develop 
new call-processing and filtering software. The business advantages are that we punch above our weight with the 
help of third parties and that they can adapt to market niches that we wouldn't see. The key technical requirements 
are that the API be very secure and very clean, and these are advantages for our own developers too. 

The network operating system is distributed over the entire collection of patchpoints and basestations. Key require- 
ments in designing it are scalability, performance and reliability, all obtained with modern distributed-OS software 
techniques such as the use of narrowly-defined servers, efficient message-passing, and process migration. 

In contrast to conventional telephony systems, which involve interconnecting several types of specialized comput- 
ers with predefined functions, we have undifferentiated hardware resources that are assigned tasks dynamically. 
This reduces design costs for us and inventory and engineering cost for service providers. 

We define a "middleware** layer that abstracts the key elements of communications (connectivity and quality of ser- 
vice) from the detailed implementations in IP 1 , AIM, frame relay or circuit-switched networks. This allows our 
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at gateways 



i „ pr Wware . to „ et high-volume consumer costs. Network interfaces 
Our hardware is based where poss,ble on PC ^ W ^^ ofS pack on the critical wireless link (we're using a 
(e g. Tl) are available off-the-shelf. but inorder to get aheadof £e ^pack on ^ ^ 

stand J due to be finalized inthe year 2W0 and £ bare . ooncs but flexible hardware 

we're developing a custom modem board for ^7^Z Zer with some flexible hardware support for the Unk 
("RISC philosophy") and will implement only the physical layer, witn 

layer. 

• • - t . m rnn version of the ARTB wideband CDMA proposal. A key 



to work either way 

1.0 The Physical Network 



r u - .1 of view with basestations connected to a network "cloud". 

Figure 1 describes our network from a physical ^^^Th^lc. A simpler picture would just connect all 
illustrating several types of connectrnty that we ^^^^^^SwIgltealAIMMdofpoinl-*. 

Maintaining the freedom to use different W^«»°* ^ f^otlSs^vemaS^ by "o^S'to 

connectivity and quality negotiating definitions will be key parts of our API. 
T^ebasestaUonsareniggedc^^ 

standard platform gives us the econormes of scale ofthe PC £*JJ*£ ? £ ^ a (simple) custom design . 
wiUh^etominasmallfo^nntaiidwmh^^ 

An option we should consider is making a PC-card (perhaps t\.i) vcrsio w» 
ThewireiessUnkwiUbeba^on,^ 

to be able to provide da. rates J^^^g^S^^ of the. wire.ess Unk. 

ceptable amount of bandwidth in a typical system, accuwu 

in a specialized DSP, and the control in a microprocessor. 

1. We'll use "TP" for Internet Protocol and TPR" for InteOecmal Property (Rights), to avoid ambiguity. The main form of IPR 
we're focussing on at the moment is the patent 
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FIGURE 1. Service provider "A" has a network of WST basestations (*BS-A") that relies on IP and 

ATM routers to provide a backbone; users have patchpotnts ("PP") connected to 
basestations with redundant illumination where possible. WST or other gateways 
connect to the public switched telephone network and other proprietary networks; users 
store voice-mail on rented disks; and the network software collaborates where possible 
with WST equipment owned by other providers such as "6". 

We need quite a flexible radio, because 3G standards are evolving and handle multiple rates, so some programma- 
bility is needed in the modem. It will initially be implemented on an FPGA, which is a conventional first step in 
ASIC development, but the final design will look like an FPGA specialized to signal processing. This may be capa- 
ble of handling some of the audio signal processing as well as radio-modem functions, and will be programmed in 
VHDL (probably with some constraints to make synthesis easier). There may be value in partnering with Morphks 
on this, if they have anything real to contribute, and wc should have someone FPGA-sawy on the radio team. Mak- 
ing VHDL code something that can safely be loaded from a library and attached to a user's process is desirable, 
since it maintains the full signal-processing flexibility that we are aiming at. 

The microprocessor will be a high-powered consumer part, and these have special support for computer graphics 
(e.g. the MMX instruction set) that we may be able to retarget for audio DSP. A DSP specialist will be needed to 
evaluate the capabilities of these machines for filtering and modem functions. A partnership with Gao Research 
may help, since they are implementing standard modems in Pentium software. 

It is not clear that we will need a conventional DSP, and avoiding using one will reduce the complexity of our soft- 
ware maintenance effort, particularly as time passes and we end up with several generations of hardware. We 
should include one only after it is proven that we can't use the FPGA or CPU to do a vital job. 
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oil processing **««• «»> configures *• W»» .*■ ™ i. to bts, i„ lcres u of a soft™™ developer 

««, „ tooled consistently. 1» " ^" ^rS^Slo provisioning usnes.so . 

S wi,c„i„ g involves moving da. .^iS^SST^Jl^-i- 

Biln.gist— 

need to think this through « « deeper level SO •> to be ate iTSled bllUuE and exclusion of expensive 

e^sh, -d » do. fo, tIMW s°fW««» «*° <►? difte. is cW^v 

resources are used efficiently even with third parlies setting up calls. 
-Provisions. . core gen-lv 

m ent purchases can be made on sound technical and business bases. 



3.0 Quality of Service 



low-cmalitv market we'll focus our system software on respecting those needs. At present voice-over-IP Blow 
networks. We should not rely on the IP infrastructure to solve our QoS problem. 

We will be implementing a system in which contention for resources is handled by user processes bidding for item, 
whe^l 212 tonally implemented centralized policies aimed at ensuring some type of fairness 
IS E££X£SELi on such things as source and destination addresses and type of traffic. 

r™.n finite canacirv on communication links in a network, there are two ways to give some packets priority: by 
JSS SSSi tne^ueues to get on links (multiple queues or different likelihood of packets ; bemg 
toSor E choosing rouL (where redundant ones exist) so that high-prionty packets .rave over bghdy loaded 
SESm 2d aavancld IP systems use these strategies internally, and we wril need to control them. 

Data transmission, such as for file transfer and Web browsing, tends to have high requirement « «* 
Curacy, while for voice calls low latency is a much more important concern -tu famously difficult to hold a 
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conversation over a channel with a 100ms delay. Statistical properties of voice and data are also quite different, 
with data transmission being burstier and likely to use TCP. (which penalizes the network for dropping packets 
under load by retransmitting them, which can cause a type of instability) Bandwidth is expensive because a given 
network only has so much of it; low latency is expensive because it restricts the use of queues in the transport net- 
work, which are needed to smooth out statistical variations in loads. 

As new types of service emerge, the balance of requirements will be different. For example, video-conferencing 
fundamentally has higher data rates than voice but the same latency requirements. At the moment it is very poorly 
handled: typical video-conferencing equipment uses heavy compression to get the bandwidth down to what can be 
handled with an ISDN line, and thereby adds so much delay that conversation is- difficult — and the picture is lousy 
to boot. If we offer the performance and price required to make high-quality videoconferencing economic, the vol- 
ume of this type of traffic may build up quickly — as fax did. There may also be a hidden market for high-quality 
audio in telephony, either in specialized areas (like radio broadcast) or as a matter of price for the general public, 
and this would also tighten specifications. These new markets could offer our customers a real edge, so we have to 
be able to offer them easily. We can't design the system so that it only works well for the current service mix. 

The telcos have revenue models based on making money from voice, and the rapidly decreasing cost of bandwidth 
puts them in a quandary: they can't afford to drop prices near costs, and until they do the new services that might 
make money won't emerge. Half of "voice calls" are now actually faxes, which also wastes resources because the 
application doesn't fundamentally require (expensive) low latency, and so businesses are emerging which bypass 
the telco for fax. The standard interface provided by an RJ- 11 jack and a line-card is limiting their ability to engi- 
neer their system. 

Subjective quality is the real measure of interest in a telephone system, and is usually quantified with an "MOS" 
(mean opinion score) by having a collection of users rate various connections on a scale of 1-4. The service pro- 
vider is faced with costs that are functions of error rates, bandwidths and latencies and an ill-defined MOS value 
model. 

Telephony has traditionally controlled load by call admission — refusing business that exceeds the volume the sys- 
tem can handle (although the effect of refusing to carry a call is that the caller dials again, so that at peak times the 
"call attempt** load goes up). The Internet Protocol model is "best effort**, so that when load increases speed suffers, 
(for everyone, at the moment) rather than using call admission. In IP, you don't set up a call, you just send the 
packet Internet audio is moving to a model in which the coder changes as a function of network load, using a band- 
width-efficient coder when loads are high and a better-sounding one when the capacity is there. This is radically 
different from the call-admission model, and probably much more acceptable to the end-user — a mechanical- 
sounding call on Christmas day is better than spending an hour hitting "rediaT. This is an area in which our cus- 
tomers can beat the telcos. 

IP has been extended to handle voice latency requirements with "type of service" bits which can be used to assign 
priorities in switching, "tags" which can force precomputed routes rather than risking delays for routing computa- 
tions, and a reservation protocol (RSVP). These features are not supported by most of the current infrastructure, 
and even with them a fair amount of network engineering is required to provide a given latency. In the Internet 
world, there is a trade-off between network engineering and raw bandwidth, in mat a network with enough excess 
capacity will be fast. Microsoft is apparently pushing RSVP hard, because Windows 98 uses it, so we can expect a 
lot of RSVP traffic from the Ethernet port. Unless they add billing support, though, their demands for priority won't 
be respected by carriers. We can add the missing piece. 

ATM (Asynchronous Transfer Mode) networks are an attempted compromise between the needs for data and voice. 
They use a call admission model, and you have to set up a route before sending data, but they can handle bursty 



Network Operating System for Telecom 



5 of 33 



traffic They specify a complicated collection of traffic models, so applications can in principle define their needs 
2 Uhe^etwork ™ in Principle make guarantees, bu, these features are seetng limited use. 

Our system has -uppon IP and voice « 

model *^~ffi£^^^£S**u we feel addresses the real problems but that 
rpTca^ot^ 

tions. and to make billing and operations respond to the nferket s real needs. 
Leaky buckets areus^^^^^ 

loads. For the radio link ^^J^^JS^^SS^ I iJU* on.y as a specification 

J TSkenfSr^e meclisms diLdy express queueing behaviour, which is fundamental to net- 

working, so they seem to be the right ones to use. 

as backpressure mechanisms. 



£3 



ID pie L price could go up. a lower-rate coder could be substituted, or a greater FER accepted. 

IP The leaky bucket model doesn't necessarily tell us everything that we need to know in setting up a path: i* * 

™ oactetSSg Sstem we wiU generally have internal queues whose length a a function of aggregate traffic and 

we war^t to S tow the sources infract. We may need to develop a more informative model, but ,t will have 
w£££L eSyTL leaky bucket, because that is what both and RSVP use. One example would be to 
Z a SSoSbSS. t^describe average rates when measured at a variety of queue sizes; a generalization 
v^uldirimlthernadcal function describing the relation between queue length and expected rate; arfyet 
more een^l would be a set of functions relating queue length to a collection of rate statistics (mean and variance. 
rJTcf SaTpercentfles). We shouldn't expect typical developers » be able to figure these things out. so we 
will probably want to develop profiling took that can do the work for them. 

3.1 QoS in ATM 

Asynchronous Transfer Mode sends 48-byte payload packets ("cells") over prearranged «™ J^™^^? 
standards include sophisticated mechanisms for defining and guaranteeing quality of serv.ee at the tune of setnng 
up a circuit, but they are litde used because of their complexity and because of jumd.ct.onal problems (appUcauons 
have no reason to be moderate in their demands). Our challenge is to use pricing to control greed, and to make an 
API that gives the QoS control promised by ATM in a comprehensible way. 
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ATM defines "service classes" A through D and corresponding "QoS classes" I through 4. This is a fairly coarse set 
of categories. "Service categories" are also defined, which are parametrized so as to allow expression of a wide 
range of needs and service guarantees. These are what we're most interested in: the user specifies the statistical pro- 
file of the traffic and in return the network guarantees a certain performance level. There are needs to police traffic 
(to check that it fits the promised profile) and shape it (to make sure that it does). 

Constant Bit-Rate (CBR) is straightforward in definition, setting bandwidth with a given peak cell rate (PCR). The user 
also defines the tolerable cell delay variation (CVDT), which he/she expects to smooth out with buffering at the 
destination. Cell transfer delay (CDT), cell loss ratio (CLR) and peak-to-peak cell delay variation (CDV) are speci- 
fied by the network as its QoS guarantee. Traditional toll-quality telephony needs this service category, but it's 
wasteful. Users would expect to pay by the minute. 

Real-time Variable Bit Rate (rt-VBR) allows bursts up to a peak cell rate and maximum burst size (MBS) and guaran- 
tees cell transfer delay (CTD) and its tolerable variation (CDVT) at a specified sustainable cell rate (SCR). A leaky 
bucket can be used to police or shape traffic to this profile. This is more like what we need for modern telephony. 
Users would probably still expect to pay by the minute. 

Non-real-time VBR doesn't guarantee CTD. It's probably more like what a Web browser would want Users would likely 
expect to pay by the minute, but would probably want a discount for slow packets. 

Unspecified Bit Rate (UBR) actually does specify peak cell rate, but not a sustainable cell rate. It's basically best-effort. 
Users might expect to pay by the megabyte. 

Available Bit Rate specifies a minimum cell rate (MCR) as well as the peak, and the network uses back-pressure to con- 
trol the flow: the network sends "Resource Management* 1 cells to the source to allow it to adapt to the capacity 
available. Users might expect to pay by the minute for the minimum cell-rate and to pay a slight premium when 
rates are high, or (equivalcntly from a mathematical point of view, but not psychologically) to pay for premium ser- 
vice but get a discount when forced back down to the minimum rate. This mechanism should be able to get the best 
utilization out of the network when users have sophisticated rate-adaptive coders, and might be a winner for video- 
phone. 

3.2 QoS in IPv6 and up 

* IP often uses ATM internally 

* priority and class 

* tag switching 

* Integrated Services Architecture 

RS VP (the resource reservation protocol) is a good start: a packet goes from sender to receiver setting up a path, 
and another comes back reserving resources (which has to be repeated every 30 seconds). The path is supposed to 
be set up with enough priority to get the effect of a lightly loaded network. Traffic statistics are specified by the 
parameters of a leaky bucket, and packets beyond the stated rate are marked as eligible for deletion. The mecha- 
nism gives us only two levels of service (high and ordinary priority). 

IP priorities are implemented differently in different subnetworks, and often not implemented at all. 

3.3 Cost and price of QoS 

* "fixed cost" at timescale of a call, hence congestion pricing 
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• provisioning "unfixes" the cost, mechanism for overall system to respond to loads. 

• provisioning motivation for provider, vs. letting congestion drive up price: competition puts ceiling on price; 
increased volume tracks lower prices at higher capacity. 

• ■ provider needs to set policies about customer satisfaction/ % potential demand satisfied, then we help imple- 

ment them. 

3.4 Warranty mechanism 

Between failures and statistical variability, QoS cannot be absolutely guaranteed; the standard commercial response 
to that problem is to offer warranties that specify how failures to meet requirements will be handled — MOS 3.5 or 
IPR? vour mone y back for the last 5 minutes, for example. This is a particularly important mechanism for defining pric- 

ing for events that are inherently statistical, because it offers a natural way to define whether or not performance 
conformed to specifications. For example, if the network offers 1000 packets free of charge for every one dropped, 
it had better keep its packet loss rate below 10~ 3 

Traffic and network performance are in fact only described statistically, and this is at the heart of the difficulty in 
providing QoS; statistics of real traffic are subtle and not easily expressed in a few parameters — how long is a ryp- 
ical voice burst? How long when the caller is a poet? The science of statistics was developed in order to model bet- 
£3 ting, and a bet is the natural abstraction of a complicated set of statistical measures. Money-back mechanisms are 

essentially bets between the network and the subscribers. 

□ 

4.0 About the Wireless Link 



m : 

*««J The open system should be useful with or without wireless links, but for business reasons we must support them 

c early. Bandwidth on these links is expensive to the service provider, and must be used efficiendy. This section is a 

Q quick overview of aspects of the wireless link that are critical to the software design. 

tD 

Radio channels are not like -pipes-, because their signals spread over a wide area rather than being carried point- 
if { to-point and they thus interfere with each other. This means that there are system-level interactions between users 

t r and that radio resource allocation is a subtle art. For example, link error rates can be reduced by increasing trans- 

f miner power, but this increases interference levels for other users and increases their error rates; the overall system 

"~ can easily become unstable. WST software has to give us the ability to use advanced techniques in this area and to 

track innovation. 

CDMA (code division multiple access) is a technique for allowing multiple users to share a piece of radio spec- 
trum. We're going with it on a business guess. There are two bey variants, one our of Qualcomm and one that 
attempts to break Qualcomm's stranglehold on relevant IPR. We'll go for the second, but with the flexibility to 
change quickly if needed. 

CDMA channels are defined by a sequence of 64, usually, "chips" (fractions of data bits) with values of ±1 ; J each chan- 
nel is orthogonal to each other, and bits are transmitted by sending the given sequence multiplied by ±1 ? Channels 



1. Actually, complex values are used, and ARTB transmits control on the "imaginary axis" and data on the -real". We may want 
to change that decision to get more usable bandwidth. 

2. Another area where we may want to innovate. 
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have equal maximum bandwidth, namely the chip rate (4.096M/s, for ARIB CDMA in 5MHz) divided by the code 
length (64, in this example, for a data rate of 64kb/s per channel) 1 . 

Channels may have different average bandwidth, though, in that system interference is set by the number of chan- 
nels actually in use, rather than the number allocated. Thus a source like voice that only transmits about 50% of the 
time uses less system capacity than a file transfer that transmits continuously. In IS-95, a system might assign only 
30 of its 64 channels, and rely on voice statistics to mean that on average only 15 of them are in use, and rarely 30. 
A data user doing file transfer would use almost twice as much of the system capacity even though assigned a sin- 
gle channel. 

high FER CDMA wireless links are typically operated with frame error rates that are high (10^3) relative to those over 
optical and wired links (< 1(^-9). Since this means that most errors will occur in these links, they are typically pro- 
tected with local error correction that can solve the problem immediately, rather than leaving it to an end-to-end 
mechanism like TCP. For voice, forward error correction and power control are used to maintain an acceptable 
error rate, rather than an ARQ mechanism that would add latency. Generally some bits need to be protected more 
carefully than others, so we would like users to be able to manipulate error control in some detail. 

cell packing and SIR vs. local BW In principle it is possible to increase transmitter power and thereby force error rates 
arbitrarily low, but then the transmitter interferes with other users nearby; thus best cell packing density is obtained 
by deliberately operating at a marginal signal to interference rauo (SIR). CDMA standards generally have quite 
sophisticated power control to optimize overall network capacity. 

Unreliable links can be dealt with by forward error correction (error-correcting codes) or by automatic repeat 
request. ARQ wins if there is no latency constraint, as in file transfer, but for voice and video it is better to get fresh 
data than to waste time on that lost and hence moderate FEC wins. 

power control is a technical issue that is particularly important in CDMA systems. Muldpath propagation of radio signals 
can cause interference between channels in CDMA, where it cannot in FDMA 2 , and so CDMA systems are limited 
in capacity by interference. The two ways to mitigate this are through careful power control, so that no-one trans- 
mits any more power than they have to, and advanced digital signal processing techniques that cancel some of the 
interference. 

Power control is done with a combination of open-loop (if the signal you receive is strong, then the channel is good 
and you can transmit at low power) and closed-loop (the other party periodically asks you to turn your power up or 
down) techniques. The need for closed-loop control means that the radio modem itself is involved in sending and 
receiving very simple packets on a millisecond timescale (0.625ms for ARIB) as part of every communication. 

use of random-access, paging and allocated channels. Radio channels may be used in an Aloha style (like Ethernet, 
with packets all sharing a channel and occasionally colliding and needing to be resent) or may be allocated to par- 
ticular users. Both styles are valuable: the Aloha (or -random access*-) style for small volumes of traffic (small rel- 
ative to a channel) and allocated channels for larger volumes (because Ethernet only gets a utilization of 1/e in 
heavy load). In the 3G standard, as in cellular systems generally, requests for service (dialling) are carried on ran- 
dom access channels, while voice traffic is carried on dedicated data channels. 

We can (and should, according to 3G) transport IP either way according to volume. Strategies for choosing between 
them can be based on traffic statistics (allocate a channel when the collision backoff gets excessive, say, or when a 

1. For further complexity. ARIB divides each 10ms frame into 16 timeslocs. so a data channel is really 1/16 of this 

2. In FDMA systems, muldpath causes fading in*f^t 
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queue length exceeds a threshold) but may sometimes be easier to specify at the application level — bandwidth 
demands of voice and video are relatively well understood. Only our users know whether a given data stream repre- 
sents voice or data, so they will have to (directly, or indirectly through their requests for QoS guarantees) specify 
the choice. 

Radio channels may also be multicast In a mobile network, "paging" is used to alert a subscriber to an incoming 
call, and pages are sent out by multiple basestations because the subscriber's location in uncertain. This is not mul- 
ticast at the logical level, because only one receiver needs to hear the page, but all of them monitor the channel. A 
clearer use of multicast is that the basestation broadcasts the interference levels that it is suffering ("you'll all have 
to speak up a little, it's noisy up here**); another is that "soft handofT (see below) involves having a patchpoint in 
redundant communication with two basestations at once, so that either can be dropped without loss of the call. 

Some carriers use a type of multicast (for dispatch and similar push-to-talk applications) at the service level (e.g. 
Nextel and Clearness Mike service), but this doesn't necessarily get implemented by sharing radio channels — it 
just overlays a virtual private network on the mobile network. 

Multicast in the CDMA environment makes the problem of closed-loop power control tricky, because enough 
power has to be used to communicate with the most distant receiver — which would have to be identified as the 
proper source of feedback. Paging and other broadcast (in the radio sense) messages are therefore transmitted at 
p full power. The need to do this reduces the bandwidth saving available from multicast. A similar problem arises if 

an ARQ technique (e.g. TCP) is used. 

Q 

IpR? For WLL, we may be able to identify the "most distant receiver" reasonably consistently and hence allow multicast 

without overkill on power. If there is enough traffic (preferably of a type that doesn't need ARQ) to make the result- 
ing bandwidth saving significant, WST should innovate in the use of multicast radio channels. 

lit 

V i 

" short codes vs. multiple codes: BW quantization and multicast (?) vs. hardware complexity at the modem 

ti 

*=f Telephony systems were designed for a constant-bandwidth service, but data services need bandwidth on demand. 

lQ ...... i 

A single CDMA channel, with rate 1/2 coding for a 10 -3 FER, has a data capacity of 32^5* and can be divided 

s n into 16 time slots that can be used efficiently with 50% voice activity; so data rates from 32kb/s down to about 

^ lkb/s can be accommodated in slots of a channel. At very low bandwidths the Aloha-style channel is best, and at 

higher rates multiple CDMA channels have to be used. 

There are two strategies for transmitting on multiple channels, and both are legal in the ARIB proposal: the use of 
multiple codes and the use of shorter codes; WST will have to make a decision, and it's a hardware/software/capac- 
ity trade-off. 

The use of multiple codes is logically straightforward: for 384kb/s, say, 12 modulators with different codes could 
be used and their results summed. One problem is that mis puts 12 times the hardware into the patchpoint modem. 2 
The second problem is that the radio signal has more dynamic range and a better power amplifier will be needed. 

The use of shortened codes is more subtle: the 64 x 64 Hadamard matrix of codes has a binary tree structure that 

means that there are shorter codes of length 2, 4, 8 32 that are orthogonal to the rest of the codes: a code of 

length 16 allows us to transmit 4 bits of data during the 64-chip interval of a single code. The receiver is actually 



1. less overhead, and also note that the "downlink" gets twice the bitrate of the uplink, but spends half of it on control. 

2. The basestation has to handle this anyway, since it may be dealing with 40 or so CDMA channels per antenna. 
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simpler for the shorter code, and while the transmitter must operate at a higher power (proportional to bitrate) it 
doesn't have an increased dynamic range (peak/average) requirement over the single channel. The problem is that 
bandwidth can only be allocated in power-of-two multiples of the basic rate, and a 384kb/s connection (for exam- 
ple) would take up 16 slots. Another problem is fragmentation: as codes are allocated and given back, the available 
codes will be scattered at random, rather than bunched together (all of the leaves below a particular node of the 
binary tree) where they can be replaced by a short code. 

WST is probably better off with the shortened codes: data services are so bursty that fine control of their band- 
widths is likely meaningless, and unused capacity is not entirely wasted (as exploitation of the 50% activity factor 
for voice demonstrates) if the transmitter is shut off when not needed because system interference is reduced. The 
main penalty will be that we have to move channels frequently between codes to reduce fragmentation. 

double illumination and handoff: relation to mobility, reliability and load-sharing 

A patchpoint may often be "illuminated" by signals from two or more basestations, and this fact can be exploited in 
several ways. In mobile systems it has traditionally (IS-95) been used for "soft handofT, so that a mobile that is 
moving between two coverage areas can temporarily send its data to, and receive it from, both basestations. Then 
when it moves entirely out of range of one, the call can continue. Since the two paths can use different codes, this 
roughly doubles the workload of the modem. 

r3 

During the period of double illumination, redundant packets are discarded, and when one is received in a corrupted 
^ state, the other is available. This obviously makes for a reliability enhancement, though at some cost in radio 

l~ resource capacity, and WST may wish to allow fixed users to run in this mode when they are willing to pay for the 

- quality. 

** \ Double illumination can also be exploited to allow load sharing between base stations (and is, in IS-95); when one 

is heavily loaded, traffic can smoothly move over to its neighbours. This economy of scope improves capacity. 



licensed and unlicensed spectrum Our system can be operated in a variety of bands with fairly minor changes to the 
radio. The choice won't make any obvious difference to the software, except for interoperability (see below), but 
might affect performance statistics. 



\S 

Fi I 
\ ~f 

in 

The two key bands for us at the moment are the 1.9GHz band, which is licensed, and the 2.45GHz band, which is 
CO unlicensed. The licensed band is expensive (the service provider may have to pay $1M and up for the license) but 

guaranteed free of outsiders adding interference. 

At 2.45GHz there are spreading rules, (10:1 spreading, which would limit any end-user to an acceptable 
chiprate/10) and power limits (lOOmW, but a function of jurisdiction) that would restrict cell size or maximum 
bitrate (a few hundred metres at 32kb/s?>. The 2.45GHz band also has a variety of interferers (principally micro- 
wave ovens and some wireless LANs, at the moment) and little control on who will enter in future, so a provider 
may run into trouble. This band is probably most interesting for campus-scale networks — perhaps a wireless PBX 
business. 



opportunities for IPR vs. regulatory and interoperability, both at the physical and logical layers (AJEUB) 

Doing our own modem has two advantages: it guarantees that we'll have one when we need it, at a price we can 
predict, and it gives us a platform on which we can in principle innovate by modifying the ARTB standard. 

One example of an innovation is to generalize the QPSK/BPSK modulation that the standard applies to the spread- 
ing code (QPSK at 2b/symbol on the downlink, BPSK at lb/symbol on the uplink) to QAM. This is generally not 
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desirable in mobile systems, because QAM signals get high bit-rate (6b/symbol for 64QAM, for example) at the 
cost of higher transmitter power, which in turn increases the radius over which other users are interfered with. For 
users close to the basestalion, though, this is not an issue, and in a WLL system basestations can be placed close to 
power users, and in a system with flexible billing the additional capacity can be rationed by price in a manner sen- 
sitive to these radio resource issues. 

At the next level of abstraction, the ARIB standard allocates logical channels to radio channels in particular ways, 
and in particular dedicates half the downlink capacity to control — which seems high and which throws away an 
opportunity to take some advantage of the asymmetrical up/down loads typical of Web browsing. We could also 
add more use of multicast and the option of allocating more Aloha-type capacity. 

To innovate on the radio, we need to know how tightly regulation will constrain us and decide how much perfor- 
mance we're willing to sacrifice for interoperability with other people's equipment. The only interoperability we 
care about is at with other terminal equipment, e.g. mobiles, since we don't plan to hook our basestations up to 
other people's mobile switching centres. At the network end, we deal with other standards through gateways. 

interoperability with IS-95 

IS-95, or "narrowband CDMA" is a standard used for PCS cell-'pbones, and has the same general mathematical 
structure as the wideband CDMA we are working with. It is possible to handle both systems at once, which is 
straightforward in different frequency slots and can even be done (with heavier signal processing and probably 
some reduced system capacity) in the same slot. Supporting PCS would be a selling point. 

Qualcomm is pushing a W-CDMA standard that is closer to IS-95, which is theirs, in a few key ways. In particular, 
chip rates in IS-95 are multiples of 9600b/s, while in AJEUB CDMA the base is Ikb/s. Qualcomm has a slightly 
lower chip rate overall, at 3(1.2288Mchip/s) = 3.6864Mchip/s as against 4.096Mchip/s for ARIB, but claim that 
their system will be cheaper to implement without spilling over into adjacent frequency bands. The Qualcomm bas- 
estations also rely on timing derived from GPS satellites, which Europe and Japan don't want to rely on and which 
doesn't work in buildings. 

need for encryption 

Analog cellular 'phones were embarrassingly easy to listen in on, and part of the advantage of the digital standards 
is that they take wiretapping out of the Radio Shack league. They are still probably not secure enough for business 
transactions (e.g. credit card transactions). What encryption there is in current commercial systems applies only to 
the radio link, with voice converted back to cleartext immediately in the network for compatibility with the PSTN. 

We can allow users to write end-to-end encryption software, although there will be some interesting legal issues 
(with the FBI and NS A) if third-party vendors use keys beyond 40 bits. We also have to encrypt and authenticate 
our own control messages between basestations and patchpoints to avoid spoofing attacks. 

4.1 FDD or TDD? 

The 3G standards are supposed to support two modes for duplexing between up- and down-links: frequency-divi- 
sion duplexing, (FDD) which needs the paired frequency bands allocated for PCS, and time-division duplexing 
(TDD) which can work in a single band and for which new spectrum has been allocated. 

There is a lot of commonality between the FDD and TDD versions, so that it will be possible to change course 
fairly easily if we start with the wrong one. Key points in favour of each are: 
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FDD • is the technique used for PCS *phoncs, and there's lots of underused licensed bandwidth out there 

• PCS compatibility would in principle make it possible to turn on IS-95 compatibility in software 

• peak radiated power levels are lower, (though W-CDMA has a TDM component that throws that advantage 
away) which will reduce power amplifier costs and may have EMC and even health advantages. 

• doesn't have H)D*s guard-time constraints, so synchronization may be simpler. 

TDD • doesn't need paired bands, so can use the unlicensed (ISM) bands at 915 and 2450MHz. The power limits in 
these bands would limit the use to microcells, and unlicensed bands are more vulnerable to interference. 

• allows asymmetric allocation of bandwidth in the up- and down-links, which can be nearly 2x more efficient in 
spectrum utilization for applications like Web browsing. 

• doesn't need a duplexer at the radio front end, for a savings of $2-$5. 

• allows peer-to-peer networking, since there is no radio distinction between a basestation and a patchpoinL This 
in turn allows even more radical system innovation, and is a reason to go TDD in the long term. 

• has up- and down-link channels that are perfectly reciprocal.(bave the same transfer functions) This allows bet- 
ter power control (possibly reducing the penalty for avoiding Qualcomm IPR) and smart-antenna algorithms 
(which increase capacity) 



5J0 Call Processing as Graph Design 

Physically, the network can be seen as a graph with the edges being communications links and the nodes being the 
computers (patchpoints, bases cations or compute servers); logically, it's natural enough to draw a similar network 
with the nodes performing computing functions and the edges still representing communication, but with comput- 
ing functions possibly time-sharing computers and with the best implementation of the communications links being 
substantially different according to where computation happens. Call processing software "wires up" this logical 
graph, and maps it onto hardware. 

Because the nodes in the logical graph can represent complex computing functions, such as voice coders, only cer- 
tain interconnections are valid. These nodes have properties (such as latency and CPU load, for example) of interest 
when wiring them up. Because the edges carry different types of information, the nodes are best thought of as hav- 
ing typed "ports", such as (in the voice coder case) those for linearly digitized signals and for CELP-coded voice. 

If edges on the logical graph represent physical communications links, they will also have properties (BW, latency, 
FER, ...). Edges and nodes are thus very similar objects, and so one approach would be to specialize them both 
from a superclass (GraphElement?); another approach would be to regard the physical link as a type of node with 
two ports (one for each end of the link), and so give it the same collection of properties as the computing node. In 
this case edges may have little meaning, and we basically connectPorts(coderA.out v FECin); we'll call this the 
Lego approach, where objects are connected directly at their ports with no explicit representation of the connecting 
edges. Choosing to maintain explicit edges at the logical level has the advantage that the logical graph may then be 
embedded directly in the physical one — which is an easy way of expressing the constraint that data has to get from 
one place to another. The "Lego" approach may be cleaner for pure computing applications. 

Because our system is open, we have to distinguish between software that represents the interests of the end user, 
which is typically concerned primarily with the logical structure and only indirectly (through its effects on cost and 
performance) with the mapping onto hardware, and software that represents the interests of the service provider. 



Network Operating System for Telecom 



13 of 33 



Processing as Graph Design 



which is concerned with sharing hardware resources efficiently among a large number of users. This is a server/cli- 
ent relationship. We would prefer both types of software to be written in WST Java, but performance concerns 
might force us to compromise on the server side. 



p 

D 
W 

in 



hierarchy or a grouping mechanism can be used to hide or show detail in the communication graph: it should be possi- 
ble to connect(this, PSTN(555-1212)), for example, and implicitly create a useful connection with default coders and 
performance; it should also be possible to send an IP packet without needing to set up a connection. In the case of 
the * phone call, it should be possible to descend into the hierarchy or group and see more detail — so that user code 
can add features, for example. Figure 2 shows some of the detail of signal flow in a typical digital wireless 4 phone F 
with encryption inserted at a suitable spot; the kind of thing that we want third-party code to be able to specify. This 
code can then choose between end-to-end encryption and encryption only over the insecure wireless link, for exam- 
ple, enforce policies on what to do if the called party is on the PSTN or has forwarded the data to voice mail, and 
perhaps choose higher-performance error correction to compensate for the sensitivity of encrypted data to errors. 

In the particular case of an IP packet, there may be no record of how the routing was implemented: so showing 
detail may not always be possible. It is not likely to be desirable to a user either, since the point of IP is to hide the 
details. An administrator who needs to know how things are likely to route would use "traceroute". 

There are privacy issues here: the classic case is that a shelter for battered women must be able to block callers 
from knowing where the call really goes, (that was high politics during the introduction of caller ID) A proxy 
should be able to hide details of how it is handling a call at its end, and then it's up to the other participants in the 
call to decide whether to continue. Hiding switching inside a PC is easy anyway, so we can't stop it 

A grouping mechanism is probably more flexible than a strict hierarchy, and perhaps a better match to the logical 
structure. Figure 3 describes end-to-end encryption and hides the irrelevant details of transport over the rest of the 
network and of the processing required to get low-rate data suitable for encryption. Hierarchy (two levels, anyway) 
naturally describes the mapping from physical (less detail) to logical (more detail, because there are several com- 
puting task per computer and several logical links perTl) networks. 
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FIGURE 2. Part of the graph representing a simple call. The blocks are described in general terms 

in Section 5.2 below. 

rules of composition would specify what kinds of networks make sense, and could be 

1 . left for the Java level to figure out 

2. implied by a strong typing mechanism for ports 

3. enforced by the objects themselves 

Point 2 seems like a good opdon. but typing is rather dynamic: forward error correction can be applied to any type 
of data, and when inverted gives back the original type. 
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FIGURE 3. 




Representing end-to-end encryption; blocks marked "caller" and "network" are groups. 
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Not all the information flows in the signal path from one subscriber to another there are also flows to and from the 
service provider's billing and management software and to the subscribers' call processing software. For example, 
if the number of uncorrected errors becomes excessive, it may be appropriate for the encoder to raise an exception 
in the call processing code so that a more robust one can be chosen. This same example also shows that it can be 
necessary to modify the graph while it is running. 

Hiding the internals of the network as in Figure 3 is probably right most of the time, but not always. For example, a 
user may want to be sure that his data is never carried on a certain type of link (one belonging to a competitor, for 
example, or one for which availability is only statistically estimated) or that it travels by two totally independent 
paths through the network (for reliability). It is possible (likely?) that some detail will be hidden from the end user 
("client") but not from the server, 

5.1 Prior Art 

Katosizsr; Mauricio thesis?. Tornado... 



SJ2 Examples of signal processing objects 

First let's look at some examples of signal processing objects, with an eye to understanding what requirements they 
will place on our system. 

The signal path 

linear and adaptive filters Classic linear filtering is used to remove DC and 60/1 20/1 80Hz tones from power-line inter- 
ference and to smooth signals for downsampling; in a digital system the downsampling and filter are usually com- 
bined in a more efficient decimation or rate-conversion block. Other applications, standard in audio but rarer in 
telephony, include tone controls and generation of reverberation. Computation loads for simple filters are very 
small, on the order of 1-10 multiply-adds per sample (80fcIPS), and completely predictable. If die processor on 
which a filter is running crashes and a new filter is restarted, there will be an audible "click" unless state is pre- 
served, and the internal state may vary quite quickly. 

The main requirement that filtering places on die system are: 

• that multiply-adds at the 16-24 bit level be fast 

• that overheads for simple algorithms be small. 

Adaptive filters tune their coefficients to the particular call in progress: the best-known case in telephony is the echo 
canceller, of which variants are designed to cancel acoustic echoes (resulting from an acoustic path from the hand- 
set's loudspeaker to its microphone) and electrical echoes resulting from system components (specifically the 
"hybrid" that converts from 2-wire to 4- wire). An echo canceller is typically a transversal filter with a few hundred 
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taps (multiply- adds), supervised by code that tries to determine the appropriate order and to turn it off when it 
appears to be unwanted or diverging. Echo cancellers that attempt to deal with acoustic echo from a speakerphone 
in an office environment need thousands of taps and sophisticated update algorithms: this area is in flux. There are 
two types of state in an adaptive filter: current coefficient values and signals. Coefficients could be checkpointed 
from time to time, but it's more expensive with signals because they vary more rapidly. 

companding techniques use "compression" algorithms that try to adjust gains (smoothly) so as to keep a signal's level 

more constant and "expansion" algorithms that adjust gains to exaggerate signal-level variations. Some techniques 
used in audio are frequency-dependent, such as Dolby companding which adjusts filter cutoffs to suppress back- 
ground hiss when signal levels are low. An extreme example of expansion is "squelch" in which signals with power 
level below a certain threshold are turned off completely to minimize idling noise. In telephony the most common 
variant is "echo suppression" (as opposed to :"cancellation") in which the signal path from the quieter user has its 
gain reduced — which reduces the loop gain for echoing and feedback oscillation. Companders use around 5-50 
operations per sample. 

Instantaneous companders work on a sample-by-sample basis, and the common A-law case is covered under "cod- 
ers" below. 

Echo suppressors cause trouble for modems, so there is a convention of watching for a 2100Hz tone at the begin- 
ning of a call as an instruction from a modem to disable echo suppression. 

A 3-way combiner takes three input signals and produces three outputs: in principle f 'C" gets voice **A+B", **B" gets 
"A+C\ etc. The idea extends naturally to N-way combining. Companding (above) is used to improve subjective 
quality by suppressing noise from inactive channels. 

One vertical application that we've discussed would leave the source channels uncombined, so that 3-way calls can 
be taken in stereo and the various voices more easily distinguished. This is mostly an application at the end-user's 
PC, because that's where the stereo speakers are. Our contribution will be to provide the packets in a timely fash- 
ion, 

voice coders are used to reduce the bandwidth requirements for voice signals. There are many types, but broadly they can 
act on the waveform, minimizing some mathematical measure like error power, they can model the source; or they 
can model what the ear will notice. Coding for compression is an active research area, and we have to assume that 
a steady stream of new coders will appear. 

"Telephony classic" uses waveform coding in the form of 8kHz A-law (or u law). Sampling is done at 8kHz on a 
signal filtered to pass the range from 300Hz to 3300Hz. The passband was defined to get good subjective scores on 
speech quality and intdligibUity, and the sample rate is designed with a 33% margin over the Nyquist minimum in 
a trade-off between network and prefilter costs. A-law and u-law are specialized 8-bit floating-point representa- 
tions, chosen as a way to get roughly constant signal-to-noise over a wide range of signal levels. By comparison 
CD sound is stereo 16-bic fixed-point sampled at 44. IkHz — needing roughly 24 times the bandwidth, i.e. Tl. 
Because speech varies slowly from sample to sample, the same quality can be had for roughly half the bandwidth 
with ADPCM which (roughly speaking) digitizes the derivative instead. 

Most digital cell-phones use a variant of linear prediction coding, which tries to model the incoming sound in terms 
of a sound source that simulates the vocal cords or airflow and which in turn drives a filter that models the larynx 
Tms requires less bandwidth than waveform coding because the larynx moves more slowly than the waveform, but 
works badly for anything other than speech or even for speech in a noisy environment. These "source coders" are 
an active topic of research and currently produce tolerable speech at output rates anywhere from 4kb/s up A typical 
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modern coder uses about 50MIPs of DSP capacity. Coders typically operate on 20msec frames of data, and hence 
add at least that much delay to the signal path. 

Source coders typically try to detect silence, and avoiding the transmission of silence typically saves about 50% of 
bandwidth on average. At the decoding side it is conventional to replace silence with "comfort noise" so that the lis- 
teners know the connection is still live. 

Source coding is hard to use for music, because it would be necessary to model a large number of different instru- 
ments alone and in combination, so early digital audio (e.g. CD and DAT) just used waveform coding with enough 
bandwidth and dynamic range to satisfy (more or less) the ear. Minidisc and digital compact cassettes brought in 
coding that reduced CD bandwidth by a factor of about 10 by using psychoacoustics. (in particular masking effects, 
where loud tones mask nearby ones for normal ears, and bandwidth can be saved by not transmitting the inaudible 
components) This type of technique can also be rate-adapted (as in RealAudio) and is a good candidate for high- 
quality speech in our networks. 

Conventional filters, companders, etc. won't work on a coded signal, so it's standard to decompress before filtering. 
In some cases we may be able to avoid this, though: for instance N-way combining can take advantage of silence to 
do companding "for free", and only needs to decode and recode during double-talk. 

MPEG (Motion Picture Experts Group) coders do the same type of thing for video signals that perceptual coders do for 
,^ music. Components of a video stream at high spatial frequencies are digitized at low resolution, (using 8*8 discrete 

cosine transforms to do the filtering) and "motion estimation" is used so that components of an image that can be 
^ derived from adjacent frames are not retransmitted. We should probably leave MPEG for the end-user's PC 

H because it is very demanding and because specialized hardware exists for it, so we are likely more interested in its 

15 traffic P^^^- Straight digitized TV costs roughly 30fraines/scc*2fXkpixels/frame*3colouis*8bits/colour for 

jH 144Mb/s. That's beyond what 3G wireless is built to handle, but MPEG2 gives similar quality at 2Mb/s — hence 

^ 3G requirement for that rate. MPEG2 is bursty, needing more capacity when the image changes suddenly. 

Q At the low-quality end, videoconferencing is usually done at 128kb/s. At this rate the coding process adds hundreds 

%Q of msec of delay and the picture is poor. 

\n * if we get a ,ot of demand ^ full-motion video, then 5MHz slots won't cut it 20MHz slots and generous use of 

%Z antenna diversity could support 10-40 users at that rate. 

\&£ 

1 0 * wc mav wam our NOS to be able to initiate processes in (colonize?) the end-user PC so that video services can 

be set up easily. 

voice-mail and its video- and text equivalents are usually thought of as pure data, but should be seen as objects with meth- 
ods for reading and writing, or as filters that persist after calls complete. The reason to generalize is to allow differ- 
ent types of coders (and encryption, and tax data, etc.) to be used in a flexible manner with voice-mail. 

Reading voice-mail can be thought of as accepting a call— albeit a time-shifted one. Voice-mails are all pending 
requests to the called party's proxy, and display the graph of the call that set them up (even though it has longsmce 
been torn down) so that the accepting party can see data type, coding and encryption needs, source of call, check 
who is paying, 'etc. 



h ^rlflf^Jf 0 "^ 1 ^ ° frcVCrscd i^* 5 » voice-mail ™* calling party stUl has to pay a deposit for disk usaee etc- in 
case the called party refuses to pay. This is a good tough use case for good billing software. ^ 
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and attached to the mail, into which you may also call to retrieve mail. This pennits 

s^ense reading voice-mail can be thought of as originate a call. 

channel coding 

- i i^fhmc Mich as XOR convolutions between the data and a given 
FEC (Forward Error — - J^^S^E^ ~~ -» » .»»**». »• « «^ 

among redundancy, power and error rate. 

i» n f FFP is triDle redundancy, in which every bit is transmitted three times. 
The brute-force (and not used) example of FEC ls ^ re £T s ^ ightforward . The algorithms used in cellular 
and the Homing codes used m memor, m£« - J^^,. , 0 dcrive but cne ap to implement in hard- 
telcphony typically have rates of 1/2 (haU ** . tatt are data and ^ pp GA techniques for these 

ware. The operations involved are generally at the brt level. ^" « uanP s > alignment would 

algorithms, but we will ^-o^*e ^ ^^^0^ on this? applying Just 

allowing the unwashed to program the FPG A. 
tempting. 

0(100) 4-bit table lookups. 

should do the encryption so thai they have a "no-fuss" secure method. 

We will have to use good encryption, including signature techniques, on our wireless control links. 
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modems 

A user may choose to plug a modem into one of our RJ- 1 1 jacks. For Internet use that would be perverse, because 
plugging into the Ethernet jack would be faster, but it may make sense for a fax machine. We could simulate a land- 
line, perhaps with ADPCM or even straight PCM, but a voice coder would destroy the data. 

The right solution is probably to detect that the source is a fax, and implement a fax modem in software at the 
patchpoint and at the gateway closest to the receiver so that our system just needs to transmit the raw fax data. This 
can be used to economize on latency as well as on bandwidth, as long as the fax at the far end can be spoofed by our 
modems. 

IP fax is seen in the industry as an easy win, because fax traffic rivals voice traffic on volume, so we should do this 
fairly early. We may want a partner to contribute the fax data pump. 

voice mail 

Current telephony practise for voice-mail is to convert calls to high-rate PCM, ship them near to the intended recip- 
ient at high bandwidth and with the usual telephony low latency, then voice-code them (to save space) and stick 
them on disk. 

We can save on network load by leaving calls coded as for the wireless link, and by accepting long latencies (best- 
effort service, say) for coded packets. We can leave the voice encrypted. We can use disk space wherever it is avail- 
able, though it is best to move it in advance close to the most likely place from which it will be read — because 
latency is less tolerable when listening to voice-man. 

Integration of a user's various mailboxes (e-mail, voice-mail and fax) is a current industry trend and a nice vertical 
application for someone to develop. It is a big project to do right, since it may involve text-to-speech and vice versa. 

links between the signal and control paths 

DTMF signalling is the familiar "touch-tone" technique of using a pair of tones ("Dual Tone") each at one of four fre- 
quencies ("Multi Frequency**) to signal switches for dialling and end-user equipment for voice-mail hell. The 
encoders can be implemented with a simple filter or a table look-up arrangement, and the receivers can be imple- 
mented with a group of filters and slicers at roughly 30-100 operations/sample. 

pulse dialling detection involves counting strings of open-circuits on the 'phone line at about 10Hz. The "flash" or "link** 
buttons often used to signal the desire to set up a 3-way call basically dial "1**. 

Both of these filters provide inputs to call processing software from the signal path. Thar path doesn't have tight 
latency requirements, unless you want to suppress the DTMF in the path to a called party. * - 

voice recognition can be used to replace dialling and to offer more sophisticated call control from a conventional tele- 
phone, or to do authentication. Computational loads can be quite large (larger than voice coding, for example, 
which is typically a component of voice recognition) and the area is still subject to active research. Computational 
loads can also vary widely as a function of the input data. 

Ideally, voice-operated services can be speaker-independent, but systems that can handle large vocabularies gener- 
ally have to be trained for the speaker. Voice authentication systems obviously need training. The need for speaker- 
dependent state suggests that these algorithms will need access to a library (which they may also want to update if 
they are capable of continual retraining). 
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The heavy loads, the use of disk resources, and the fact that voice coding is typically the first step combine to sug- 
gest that a typical voice recognition application would do voice coding on the patchpoint but might do the rest of 
the crunching on a compute server at the basestation side. The right voice coder for recognition isn't necessarily a 
standard one for wireless, so we might have the interesting situation that choosing to use voice recognition some- 
where in a call graph constrains the voice coder elsewhere. Obviously the call setup agent could just ship both kinds 
of data, but that would be an expensive use of the wireless resource. 

call progress tones like dial-tone and ring and busy signals give call-processing software a way to drive the signal path. 
Modern systems also allow the use of speech clips, although this brings up some interesting questions of how to 
handle multilingual environments. Presumably a language preference is part of a user's state. 

Users who have a good display device available would rather use it than hear ringing tones. This is an interesting 
example of the need to be able to abstract part of call processing — we'd like to be able to "plug in" arbitrary ways 
of notifying the end user that a line is busy without changing the rest of a piece of call processing software. 

IP packets to and from the Ethernet port 
We want to be able to filter IP packets that come in from the Ethernet port, too. There's not necessarily any warning 
that IP packets are coming, since IP is connectionless, but that just means that IP filtering is set up by default. 

IP classifiers assign different types of traffic different priorities. They lake a single input (unclassified IP) and produce 
multiple output streams. We'd need to classify packets before they go over the expensive wireless link so as to 
implement the user's own policies on what to pay premium rates for. A default classifier might (for example) assign 
a lower priority to Web traffic than to IP telephony, or give one particular Ethernet source higher priority than oth- 
M ers. Classifiers belong at the network input and perhaps also at both ends of the wireless link. 



m 
in 



i5 



IP classifiers can also manage traffic in the other direction, regulating flows onto the Ethernet from the patchpoint. 

traffic shaping, traffic policing and radio resource management go together for DP packets. Traffic shaping uses leaky 
buckets (etc.) to force traffic statistics to match the profile promised in a QoS negotiation; traffic policing is the 
same thing when done by trusted code at the input to a network. We'd presumably have a standard "traffic cop" fil- 
ter installed as part of any IP path. This is an example of a parameterizable filter, with cell rates and bucket sizes as 

parameters. 



iB Because IP flows can be very bursty, we may need to allocate new radio channels/slots when a queue starts to build 

j. fl up, then give them back when it empties. In the absence of traffic (when its queue has been empty for a length of 

ume comparable to a channel setup delay, for example) we'd assign a stream to a collision-detect radio channel 
The channels are radio resources, and management policies are needed to share them efficiently among data flows 
(including flows among unrelated but nearby basestations and patchpoints) - - 

header compression is used to avoid sending 40 bytes of IP headers over the radio channel. KIP is one standard, and cir- 
cuit switching can be regarded as an extreme case of header compression-source and destination addresses are 
Known at channel setup. 

Compression techniques are particularly sensitive to state: if the decompression filter at the other end of the link 

deS wlT^^ Ste,C - °* &C ™ y * P™*** nusdirected. There ar« three obvious phBosopWeTfor 
dealing with this: checkpointing critical state information; adding a global "reset" signal that is passed to all filters 
after a crash recovery and which could cause resynchroaization; and adding a privateTestart" sSberwen mT 
compression and decompression filter. signal oetween the 
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Radio Resource Manager 



IP packets originating from the Ethernet port are classified, compressed, 
shaped/policed, and then handed to radio resource management software that runs 
across the radio link. 



Passing state between compression/decompression pairs of filters is a problem in general, not just for crash zeco\ 
ery, because state information may have to be passed at a higher level of reliability than the rest of the data. This 
suggests that there should be a "side channel" set up between pairs, as shown in Figure 5. 




traffic path 



FIGURE 5. There is a need for reliable side-paths for state information. 
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firewalls implement security policies that control information flows between the inside and outside worlds, for example 
by forbidding telnet sessions. Firewall niters in our patchpoint would make for an interesting low-cost product, per- 
haps for small businesses. 

gateways convert IP traffic to and from other forms, for example to PSTO voice traffic. Basestations with PSTN interface 
cards can serve as gateways, or wc can use third-party gateways by adapting to their protocols. 

caching of Web pages is a useful method of controlling bandwidth, but can be very tricky to implement because some 

Web paoes are dynamic. In the case of the IBM/Kasparov match, for example, large volumes of traffic were gener- 
ated forages that changed on a timescale of minutes. An ISP could implement a cache to reduce the traffic onto 
the backbone while speeding up response for subscribers. 

A cache shares information between users, so it doesn't necessarily show up directly in a user's call-graph. It logi- 
cally fits as part of a gateway to the Internet backbone. 

There are tricky legal issues, such as whether caching violates copyright; technical issues, such as whether caching 
makes cookie-based pages malfunction; and business issues such as whether it makes advertising banners and 
referrals miscount. Getting these things right makes caching difficult, but the performance win makes it worth- 
while. 

packet formatting e.g. for ATM and reassembly 
figuring out tags; H.323 

links between signal and OAM&P 

Quality failures: queue overrun/packet drop: algorithm failure/residue; complaint 
resource failures or shortages: mostly at the mapping stage but also: voice-mail overrun. 

links between signal and billing 
resource use: PSTN, mailbox rentals, CPU, 

900 numbers, e-payments 



5.3 The signal-processing object 

We will have a library of signal processing objects, instances of which can be wired together to set up communica- 
tions graphs. These objects will have "ports" between which connections are made. What are the properties of the 
objects and their ports? Ports are part of a filter object, so we'll start there. 

strongly typed ports 

Ports should be strongly typed so that meaningless connections are difficult to set up: a voice coder that expects 
integer samples of a voice signal will do nothing useful if driven by the output of an FEC coder, for example. Pre- 
sumably this also means that we have a library of "interfaces- (in the Java sense, Le. types of ports) that new filters 
are expected to implement. 

Ports may have a hierarchical structure; handshaking or backpressure signals, for example, may be associated with 
a data stream. 

Ports usually have a direction to them (input or output), although they may have components that go in the opposite 
direction, as for example (again) when a handshake ts involved. 
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Examples of port types can be found in the list of filters above, but let's look at them explicitly: 

• sampled representations of audio signals: e.g. linear, A-law, ADPCM, samples of prc-emphasized signals. Pons 
of these types are also parametrized by sample rate, number of bits, and the characteristics of pre-emphasis fil- 
ters. 

• coded representations of signals, e.g. codebook-excited LPC. These can usually be parameterized (e.g. by filter 
length and frame and sample rate) 

• alerts, which signal the occurrence of an event such as a hang-up or detection of DTMF, and reset ports 

• billing ports, through which representations of money flow. 

• parameter ports allow call-setup software to adjust such things as sample rates, or to read them. 

• state input/output ports synchronize complementary pairs of coders and decoders. 

• IP streams, and compressed versions (e.g. RTP streams) 
ports and their types; e.g. A-law; alert; $; OAM&P; control 
managing ports on queues 

default port connections 

resource requirements 
resource requirements eg. CPU average; CPU max?; disk; hardware (e.g. for drivers); 

setting resource requirements 

latencies 

processing latencies 
libraries 

certification and privileges 
certification and measurement philosophies 

privileged/trusted filters needed for billing, OAM&.P, NOS exec and scheduling. Must run on trusted hardware. 

5.4 The link object 

physical or virtual? It'll change, 
characterized by BW & QoS 
setting BW 

latency, including queues 

guaranteeing vs. measuring BW and latency 

reliability 

setting reliability; recommended coders 

costing API (forservice provider's pricing software) 

billing and OAM&P ports 
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5.5 Call processing 

5.6 Features to demonstrate 

• role of demo vertical apps 

• stereo 3- way 

• "here I am" call forwarding; uses caller ID if possible to remotely reroute forwarding — needs authentication 

• call forward that works through a switchboard by advising the caller of what's happening — or dials the exten- 
sion 

• e-cash calls 

5.7 Project management 

Bulletproof Java is a clearly definable separate project and a potential stand-alone product. If we can control it through 
licensing (cheap to everyone except competitors?), then we get a little bit of revenue at the same time that we create 
a community of software developers. We can hive the development and even some of the design off to TCS. Once 
£j it's there, we can move call processing that we have done in ordinary Java over to it and suddenly start to demon- 

ic* strate survivability. 

J--»f There are some high-level design trade-offs to think about. Ideally, a complete copy of the program state would be 

j;^ maintained on a backup machine at all times, but this would be extremely slow and synchronization with calls thai 

W change state of the network would be very tricky. Is it good enough to have the state of particular (programmer- 

Ifl define) objects protected? 

'-J 

n 

P 6^0 Call Processing: Ser vers, Agents and Managers 

\5 

fy intro: what is call processing? Setup, monitoring, teardown 

* 0 clarity far individual 

HQ performance for system 

6.1 Proxy 

The key feature we need for call processing is that each end user is represented by a "proxy" in our system, which 
deals with 

• incoming calls, deciding which ones get to ring a 'phone, which get busy signals, which go to voice-mail, etc. 

• billing, representing the end user's policies on what to pay (900 calls? disk space for voice-mail?) and how. (bill 
me or Visa?) 

• outgoing calls, using special "speed-call** directories or voice-dialling software, etc. 

Proxies can also represent groups of users ("the operator", "911 dispatch**, etc.). Generally, anything that can pay 
bilk can have a proxy. It is the responsibility of the proxy to decide which telephone to ring. 
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Users outside our system will need "generic proxies" representing legitimate uses of the PSTN, for example, or to 
represent a PSTN calling party's intentions (caller ID, for example) to a WST proxy. A WST user who "roams" into 
the PSTN will need to be able to inform his/her proxy of how he/she can be found. 

Well-known telecom sendees serve as "use cases" for a call processing architecture. A telephone call may be redi- 
rected by call forwarding or (on busy or no answer) to voice mail, for example; its billing may be redirected by use 
of 800 or 900 numbers; and during a call a third party can be added to set up a conference call. In a cellular "system, 
users must be paged over a large area to find them for a call, and incoming calls may be redirected (by means of the 
"home location register" and "visitor location register" databases) to remote locations. The user's routing model for 
simple Internet packets is as simple as that for a 'phone call, but advanced IP features such as multicast, QoSxon- 
trol and mobility again bring in call setup and billing concerns. 

In a telephone system, call features may conflict (busy wait and voice-mail features have different responses to a 
busy signal, for example). A proxy architecture takes care of this in the sense that a program has to be written to do 
one thing or another when sensing "busy". The difficulty will return if we try to implement a feature-level descrip- 
tion language for call processing. 

We're assuming that call processing software will be written in Java; key requirements for the language are: 

• excellent security 

• a large community of experienced developers 

• object orientation 



V*' 

b 

M- • simple net-based distribution mechanism 

CO 

ifl Proxies must pcrs ist in the presence of patchpoint and basestation failures, so that (for example) a user's forwarding 

Kl instructions don't get lost during a crash. 

c 

p Directories can be implemented as distributed databases, for scalability, and custom versions can exist. A directory 

yi really belongs to a user or group of users, rather than to the network provider; in an open system, we want a private 

j\i "yellow pages" to prosper, for example, and anyway we can't forbid it because it could be provided (less effi- 

I^p. ciently) from any IP address. 

A "call manager" will be needed for setting up complicated types of calls. In setting up a three-way call, for exam- 
ple, the question arises of what to do when the originating party hangs up; does the call drop? If not, either the call- 
ing party may find itself handling a number of calls of which it isn't part or it will delegate the task to a call 
manager. The call manager mechanism can also be used to simplify the task of call setup for simple calls. 

Proxy as state machine 

Proxies define a user's policies for making and taking calls, and complex policies will entail complex software; but 
we want policies to be easily defined. The combination of complexity and ease of use implies that we will want to 
impose a structure on the coding of proxies that makes for clarity and allows some sort of intuitive interface. The 
sequence of actions involved in taking a call can be described by a state machine, and the state machine can be 
edited as a graph — one which is in turn responsible for setting up switching graphs. 

Figure 6 shows the piece of a proxy that implements the standard dialling model, for example. This representation 
can be edited graphically, and different blocks substituted to allow voice dialling or different interpretations of 
numbers, (e.g. the PBX convention "dial 9 to get out" or something where press-and-hold of a digit gives speed 
dialling) v 
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FIGURE 6. 



Section of a call-processing state-machine responsible for initiating calls according to a 
conventional dial-tone model 



P 

in 
si 

ru 
in 
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call setup is: set up your half the ideal way. ask a manager to get you a connection to someone else; they respond 
with counterproposals, the manager adjusts your graph to work. You can catch changes, or just let them go 
through, 

you could have a state machine that goes through a sequence of offers 
monitoring is: you can catch signals if you like. 



Negotiating a connection 
E911 



6.2 Directory Server 

distributed nature; like DNS, maybe LDAP 



World Cup tickets 



6.3 Mapping Server 



6.4 RFQ Server 

For telephony, we need a mechanism in which: 

1 . the call manager asks for a quote on the cost of service for its traffic load at a certain QoS. The RFQ mechanism 
may be quite subtle, specifying a price/performance trade-off, but must degenerate easily to standard models. 

2. the network responds with an offer of a certain capacity and QoS at a price and with a warranty. This response 
should be as informative as possible: for example, a response to an RFQ asking for an impossibly low latency 
should respond with an offer at the minimum practical latency. 

3. the call manager accepts the quote, or perhaps tries again at a lower bandwidth or QoS. 



26 of 33 



Network Operating System forTetecom 



4. the network sets up channels and reserves bandwidth. 

5. the call manager alerts the various parties to start talking. They handle ringing/busy etc. themselves, but signal 
the call manager on hang-ups, DTMF tones or hookswitch flashes, etc. The call manager is also signalled by the 
network on failures to achieve contracted performance, and may renegotiate rates while a call is in progress. 

6. the call manager alerts the network that the call is over 

7. the network tears down the call 

IP is a special case of this, in which a low-QoS ("best effort") low-bandwidth (compatible with Aloha channels, for 
most users) path to arbitrary IP addresses is negotiated at power-up. The call manager monitors queue lengths on 
either side of the radio link (being signalled when queues start to fill, for example) so as to adapt its QoS requests to 
load and bandwidth availability in a price-sensitive manner. The call manager is also signalled when packets are 
dropped. 

A more advanced IP strategy typically involves difFerent QoS as a function of parameters that can be deduced from 
the JD? header, (source and destination addresses, ports, TOS bits, etc.) In our system this is enforced by filter pro- 
cesses in the patchpoint and/or network that segregate the user's IP traffic into a number of logical streams, each of 
which can have its own call manager. This allows third parties to offer 'Turbo Telnet", for example, whereas in a 
typical modern network the priority of Telnet is fixed centrally (and low). 

P Call Graph as API for negotiation 

*t 

£xJ For new services, we cannot assume that there is a single pipe at a given bandwidth and QoS involved in a call; for 

M example, a 3-way video-conference call might have one of the branches operating as voice-only at a much lower 

CO rate than the video branches. Our API for negotiation has to capture the whole structure of the call. For this reason, 

j : fj and to avoid adding new constructs, we will use the call-graph itself as the key specification both of desired service 

* =J rpR? and billing method. 

E 

{□ Essentially, the call-manager software hands a "schematic" of the desired call to the RFQ server, which looks at the 

kg "traffic cops** and similar blocks to determine a price, then sets parameters in "teller'* blocks that feed money into 

j y key components. The modified graph is then returned to the call-manager for approval. 

Ijj Figure 7 shows the graph that a call manager might pass for an RFQ on a simple call with a given bandwidth. The 

W switching sub-structure is enclosed in a high-level block, and a particular payment method is attached to the entire 

(0 block, but with the per-minute rate not yet filled in; that's the job of the RFQ server. 

For use as part of the RFQ process, the calling graph needs to be able to express anything of interest to the user or 
the network, including latency, frame error rate, and nature of warranties. These things are expressed by including 
policing blocks in the call graph that enforce or test for compliance. The policing blocks have to trusted, which is 
an additional task for our certification group. We also have to be careful that a spoofing attack doesn't undermine 
the integrity of billing. 

latency cops specify allowable latency. If we have accurate time references available, (e.g. by using GPS) then the struc- 
ture of Figure 8 could be used. A timestamp is added to outgoing packets (perhaps all of them, in the case of IP, or 
perhaps just those starting bursts, as in telephony), and checked at the receiver. 

The latency cop can also implement the buffering needed to eliminate the variability of incoming delay, which is 
important in voice applications. In this situation, the RFQ process estimates the worst-case delays through the 
channel, then sets a parameter in the latency cop that sets its maximum buffer sire and how full it should initially be 
before passing data on. 
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FIGURE 7. 



A simple call ready for a quote: this graph is passed to the RFQ server, which sets the 
rate (?/minute) and passes it back. 
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FIGURE 8. 



A call with a latency specification and a warranty. 



When the latency cop detects a failure, it signals a warranty violation to die warranty service (Figure 8), which in 
turn reduces the time actually charged according to an agreed policy. The call manager sets up its desired policy, 
and the RFQ server may choose to charge a premium in order to assume that risk- 

If absolute time references are not available, essentially the same structure can be used to measure and enforce 
round-trip delays. The policing function moves into the timestamp service, and an echo mechanism replaces the 
original cop. The echo mechanism may be rolled in with ARQ (e.g. for TCP) to save traffic. 
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Buffering to eliminate delay variability in each one-way path is more subtle in the case that absolute time refer- 
ences are not available, because the average input and output rates might not match. A "frequency-locked-loop" 
type of approach in which output sample rates are adjusted so as to keep a buffer size stable is used to solve the 
problem. 

FER cops can be rolled in with error-checking at the destination, and work in much the same way as latency cops: when a 
frame error is detected, they signal a warranty failure. 

detailed billing services are just interposed between the body of the call and the ultimate source of money (e.g. VISA), as 
shown in Figure 9. The call manager passes the billing service a copy of the entire call graph on call setup (so that 
it has all the necessary information to describe the call), and it also receives copies of warranty-failure alerts. It 
stores its results on rented disk, which can then be read through a Web interface or printed and mailed. 
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FIGURE 9. 



A call with detailed billing 



multiple billing sources, are handled by attaching different money sources to different subgraphs, as in Figure 10. This 
will be useful in the case of point-to-multipoint services, like MB one or other pseudo-broadcasts. 

976 calls or other calls that involve one user paying another are set up similarly: the payee includes a payment cop in a 
subgraph that will insist on money flowing in at a certain rate or on certain signals, and offers that subgraph to 
potential clients — who pay service charges both to the system and the payee, as in Figure 1 1. Hie RFQ process sets 
up these third-parry flows in the same way as ordinary system charges. Because the 976 operator does not include a 
money source in the service subgraph, he can't be charged. This is also an example of a case in which the 976 ser- 
vice operator would not allow clients to descend the hierarchy and sec the internal structure of the service (such as 
home * phone numbers of the employees). 

Robbie Q2 

Telephony classic; one QoS t one price take/leave, 
broker mechanism; brokers taking a cut. 
charging for RFQs 
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RGURE11. 



A call with multiple independent bills, e.g. for a broadcast-type service. 




A 976 call. The 976 service provides a black box with voice and money ports, to which 
a caller attaches money and signals. 



6.5 Link Manager 

Implementation 



Figure 12 describes a proposed structure for the software. A distributed communications substrate is interposed 
between user processes and the underlying machines, so that processes can generally be moved from one machine 
to another without being aware of it (either to distribute load or to recover from failures). 

Processes running in the system come from different sources and accordingly get different treatment in terms of the 
trade-off between security and performance. CaU-processing functions acting on behalf of the end users run in a 
protected "sandbox" environment on a virtual machine; those working on behalf of the network provider may run 
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real-time kernel 




real-time kernel 
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Structure of the proposed network operating system. Signals pass through filter 
processes "F\ which also implement drivers and performance-sensitive functions on 
behalf of the network. Call processing on behalf of users is handled by "CP" processes 
running in a secure virtual machine <*VM") environment, which also includes 
checkpointing functions that can transfer control on failure to a "ghost machine" (shown 
as a dotted box for one of the call processing blocks). AH these processes run on a 
common software communications layer, which places them on appropriate physical 
systems and arranges for their connections. Server processes ("S") also run on the 
communications substrate, but do not have the hard real-time constraints of the filter 
processes; secure call-processing functions are one type of server process. 



there, but may also be implemented directly as processes running on the network operating system. User processes 
running as "filters", i.e. with the hard real-time demands that come from being in the signal path, also run directly 
on the communications substrate. Processes belonging to different users are protected from each other by the usual 
OS mechanisms (memory mapping, file privileges, etc.) but the source is also reviewed by WST. Filter processes on 
the same machine and part of the same call may share an address space and a thread of control, with data being 
passed with a function call mechanism and with connections to other hardware being handled by a stub that adapts 
a function call to a socket-type mechanism. These filters would still be dynamically linked, even with the function- 
cal mechanism. 



Question for Mike and Mauricio: can we still share code segments among many users (20 people all using the same 
vocoder on a particular machine, e.g.) with this function-call mechanism? I guess with enough pointers and with 
functions mapped into different pages it should be fine and might cut down onl-cache misses? Is this D?R? 

We have to shop around for the right kernel, but QNX is a candidate. A mix of business and technical issues should 
be considered: - - 

* how quick is task switching? 

• can we get the source, both to check for security holes and to extend it (for example to allow the scheduler to 
enforce advanced CPU-sharing policies). 

♦ what per-unit price is the license, and what special conditions are involved (e.g. the Linux copyleft) 

Migration done at execO level? Daemons watch for things that need to migrate, either because watchdogs fail to 
bark or because queues start to fill up? Queue size anomalies reported to OAM&P. 

processing objects: C code, may assume MMX (good for DSP, likely). Certification involves our seein* source 
which is also escrowed to us so that failing third parties are not a problem for our users and so that we ^an coordi- 
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natc a recompilaiion/rewrite binge to a new CPU if necessary. Ports implemented a bit like sockets, but the system 
can retarget them (to a port on another process, including as a special case a driver to a network device). Ports better 
be fast Backup of data that must survive crashes handled (in and out?) through a standardized port?. 



this section should outline our plans for patents, trademarks and copyright 

8.1 System patent 

See 'Telecom Network" 

This protects a network of patchpoints and basestations, all running simple real-time kernels, all coordinated by a 
middleware layer that gives communications applications a view of the overall system where details of connections 
may be abstracted out 

8.2 Graph patent 

See "Method for Configuring Communications Systems" 

This protects the use of a graph structure to describe desired connections, for use in the overall system of 
Section 8.1. 

8.3 Billing/RFQ patent 

Patent sketch not yet written. 

This protects the RFQ process: it's a server patent for the system of Section 8. 1. We also protect the use of the 
graphs of Section 8.2 as an APL 



8,0 IP portfolio 



claims 



1. 



use of RFQ mechanism to permit third-party call setup 

use of calling graph with policing functions to specify RFQ mechanism 

brokers to translate between system and user pricing models, accepting risk 



2. 



8.4 Mapping Server patent 



Patent sketch not yet written. 



This protects the mapping server. A system as in Section 8.1 having a process or processes that add functions (pre- 
ferred embodiment as per Section 8.2) to permit a simplified description of a telecom "call", possibly including 
blocks representing QoS policing functions, to be mapped onto the physical network. 



8.5 Middleware for Connectivity and QoS 
Patent sketch not yet written. 



Details on functionality of middleware layer used in Section 8.1. Is this a continuation? 
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□ ABSTRACT 

M- 

£3 A flexible telecommunications system and a method for allowing flexible and reliable 
yi configuration of same. 

1* 

O BACKGROUND OF THE INVENTION 

I™ Overall Background 

MI 

pi telephone systems with "dumb terminals" + large legacy + function too fixed, advanced 
ly features hard to do 

Internet with smart but untrustworty terminals 

variety of access methods 

variety of switching standards 

Desired Invention 

Therefore, an invention which... is desirable. 

SUMMARY OF THE INVENTION 

should be organized by claim 



Our system comprl 




1 . A collection of "terminals" (note: we need a better name, since "terminal" means 
the 'phone or the X terminal, and has to be the end of the line: patchpoints? On-ramps? 
TelePorts?) to which the subscriber connects telephones and networked PCs, and which have 
wireless links to... 

2. A collection of basestations, owned by a service provider, interconnected by ... 

3. ... a backbone network, such as an IPor ATM network or a collection of T1 lines. 



4. A distributed operating system on all of the patchpoints and basestations, which 
supports ... 

5. ... "filter" processes that can be moved between computers based on load and 

that... 



6. ... can also be moved on failure of a basestation or patchpoint, perhaps with loss 
of some process state and I/O packets, but without corrupting the structure of interconnection of 
^ I/O "ports" of the processes, which represents the logical behaviour of the system, and which is 
p controlled by ... 

1 : 

O 7. ... a highly fault-tolerant Java-like (note: explain relevant Java features — 

i :* sandbox, objects, API, download?) software layer that is so rigorously secure that it can be 

£0 safely opened to third-party software developers. 

Ul 

SI Application 



U This is the architecture of our data-centric telephony system. Subscribers plug telephones and 
uj computers into the patchpoints, and software running on the patchpoint relays coded voice or 
* y data through a wireless modem back to the basestation, and thence through a collection of 
«Jj pieces of filtering software (such as coding translators, three-way-calling junctions, DTMF 
detectors, etc> to other subscribers (or their software proxies). 



m 



Reliability is very important, hence the features relating to redundancy. There is implicit link 
redundancy through the use of a wireless standard that supports handoff. 

Relation to Known Systems 

Elements 1-4 could describe a particular topology of a networked operating system, with the 
relatively minor restriction that 1 and 2 have a wireless interconnection, and with a particular 
ownership structure. A network of servers with X terminals would look a lot like what we 
describe to that point. We will in any case wish to extend our system to operate in a wired 
network and with different ownership structures, so these restrictions are not key. 



Element 5 describes the addition that platform computing makes to SUN and NT operating 
systems. The filter & graph view of real-time computing (part of elements 5&6, but for a single- 
user environment with simplified resource management) was in the Katosizer. 




Element 6 is unique. Redundant systems exist, but can only economically switch processes on 
failure between very tightly coupled machines. They are designed to operate with no loss of 
information, whereas we compromise on that to allow realistic performance with redundancy 
between loosely coupled machines. 

The comment "perhaps with some loss ..." means 

• that we can generally tolerate "clicks" etcjhat result from losing packets or having filter 
states change discontinuously, but we cannot tolerate an error in state that would result 
in the remainder of the call being useless — for example loss of the codebook in an 
adaptive vector quantizer. Applications that cannot tolerate errors will have to use 
expensive backup mechanisms and multiple paths. 

• that we therefore have a mechanism in the filter API that allows backup across the 
network of state information that must be preserved (keepSafe(Object o) ?), and a 
related mechanism that extends TCP so that we can be certain which packets have 
made it to the other end even when the originator fails during the wait. This will be IPR. 



There will be a good deal of IPR in the definition of the filter objects and API, particularly in 
areas that allow us to make development of filter software as open as possible. 

O 

Element 7 is of central importance for us, since it is what makes it possible for a small company 
p to compete with the majors. There will be lots of nuts-and-bolts IPR, but we need to do a very 
Mr careful job of defining and protecting it. 



BRIEF DESCRIPTION OF THE DRAWINGS 

m 

3 DETAILED DESCRIPTION OF PREFERRED 

IV EMBODIMENTS OF THE INVENTION 

In 

1.3 A collection of computers interconnected by a network, some of the computers being connected to telephony hardware 
£0 (including anything with microphones, loudspeakers, possibly LCD or video displays and possible videocameras and ...), 
with a software system that enables software components that perform particular tasks (such as recoding, conferencing, 
etc.) to be interconnected and for the connections to be dynamically changed. Use of sockets or function calls or 
threads or.... 

WE CLAIM 

Broad 

1 . Elements 1-6 of Section, "Summary of the Invention" on page 2 

2. Elements 1-7 of Section, "Summary of the Invention," on page 2 
1 . items 1 -6 for telecom? 



2. items 1 -7 for telecom 



foWele 



3. 1-6 foWelephony in particular 

4. 1-7 for telephony in particular 
Fair and Square 

5. 

Nuts and Bolts 

6. f 

DRAWINGS 

Drawings describing the problem 

Drawings describing the invention in general terms 

Drawings for preferred embodiments 
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li ABSTRACT 

i* 

£8 

in 



A structure for configurable software systems applied to tele^mmuni^tionsthat allows a 
JbS of software components to be interconnected in order to obtain des.red behaviours. 

BACKGROUND OF THE INVENTION 

Overall Background 

K Toi^rnmmunications systems need to process the data flowing through them in complex ways, 
change. 

SS^fJSi^Stato in general, such as electronic mail, remote compufng, file 
frinsferbetween computers or Web browsing, there are needs for security funcbons such as 
VSSL and encry^ton afwell as datastream functions such as traffic shapmg. error handhng. 
prioritization, caching, format translation and multicast 



While telecom systems are already complex, new services such as video telephony, Internet 
games, video on demand, Internet audio, remote collaborative work and telemedicine are 
appearing. These services will need new families of features to be overlaid on the existing 
network, rendering the software development task yet more complex. 

The complexity of present telecommunications systems software, and the extensive interactions 
between its software components, makes the development of new features very difficult 
Software development is therefore limited to a "closed" group of trusted developers, which 
reduces the talent pool available and shuts out developers with new ideas for niche markets. 

application to the modeling of communications systems 

application to the modeling of physical systems 

applications to transaction processing and to computation in general (Mike: I think it's easier to 
make one patent and to arrange ownership of various markets through contract than to try to 
subdivide a patent, because the umbrella claims have to be smaller in the two-patent case: it 
will be easier to squeeze between the gaps between two umbrellas than to get through one big 
one.) 



Desired Invention 

Therefore, an invention which allows the flexible definition of the processing of signals or data 
streams in communications systems, computer systems and computer networks is desirable. 



SUMMARY OF THE INVENTION 

organized by claim 



BRIEF DESCRIPTION OF THE DRAWING 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 



WE CLAIM 

Broad 



1 . Anything using graphs to connect pieces of software (need to cut that down a 

bit...) 



2. A configurable software system comprising 
a library of filter processes; 
a software process capable of connecting them in a prescribed fashion; and 
an operating-system kernel capable of executing the connected processes 

3. the software system according to claim 2 implemented on a plurality of 
computers interconnected by a communications network, in which connected filter processes 
may either run on the same or on different computers. 

Fair and Square 

4. the software system according to 3 applied to the processing of data streams in 
a telecommunications network 

5. connected processes able to run in the same address space 
Nuts and Bolts 

6. function-call model 

7. insertion of drivers for remote connection 

8. strongly typed ports 

DRAWINGS 

Drawings describing problem 

Drawings describing the invention in general terms 
Drawings for preferred embodiments 




What is claimed is: 

1 . In a telecommunication network including a local client, a local server, a remote server 
and a remote client, said local server and said remote server being operable to 
communicate via a plurality of communication media, a method for selecting one of said 
plurality of communication media to carry a communication service between said local 
client and said remote client, comprising the steps executed at said local server of: 
monitoring performance parameters of said plurality of communication media; 
calculating expected performance of said plurality of communication media for handling 

of each of said various modes of communication; and 
determining a usage rate and a warranty to offer to said local client for said 

communication service between said local client and said remote client. 

2. A telecommunications network as claimed in claim 1, further comprising a third party 
server electrically connected to said local server, wherein said steps of monitoring, 
calculating and determining are executed by said third party server. 

3. A telecommunications network as claimed in claim 1 , further comprising the steps of: 
monitoring operation of a communication service; and 

responding to said warranty being violated by providing compensation to said local 
client. 

4. A telecommunications network as claimed in claim 1 , wherein said step of monitoring 
operation of a communication service comprises recording packet losses. 

5. A telecommunications network as claimed in claim 1, wherein said step of monitoring 
performance parameters of said plurality of communication media comprises: 
transmitting sample packets to predetermined destinations within the network and 
calculating the available quality of service. 



6. A telecommunications system comprising: 
at least one basestation; 

at least one client access point, each of said client access points being electrically 

connected to a single one of said at least one basestation; 
a backbone network comprising a plurality of communication lines, each of said at least 

one basestations being electrically connected to said backbone network; and 
a distributed operating system on said plurality of basestations and said plurality of client 

access points, being operable to provide switching, billing, voice and data 

services over said telecommunications system. 

7 A telecommunications system as claimed in claim 6. wherein at least one of said client 
access points is electrically connected to at least one of said basestations via a wireless 
local loop. 

A telecommunications system as claimed in claim 6. wherein said distributed operating 
system is a graph design. 

A telecommunications system as claimed in claim 6. wherein said distributed operating 
system is implemented as a middleware layer, allowing freedom for third parties to add 
operationallity to said telecommunications system. 

In a telecommunication network including a local client, a local server, a remote server 
and a remote client, said local server and said remote server being operable to 
communicate via a plurality of communication media, a method for selecting one of said 
plurality of communication media to carry a communication service between said local 
client and said remote client, comprising the steps executed at said local client of: 
selecting an available communication service on the basis of a usage rate and a 
warranty. 



8. 



9. 



10. 



A telecommunications system comprising: 
at least one basestation; 

at least one client access point, each of said client access points being electrically 

connected to a single one of said at least one basestations; 
a backbone network comprising a plurality of communication lines, each of said at least 

one basestations being electrically connected to said backbone network; and 
agent software operating on said at least one basestation and said at least one cljent 

access point, for negotiating communication services over said backbone^ 

network. 

A method of communicating voice over data network calls between three or more 
participants comprising the steps of: 

for each participant, mixing voice streams of all other participants together to create a 

composite incoming voice stream; and 
transmitting each said composite incoming voice stream, to the corresponding said 

participant. 

A method of CDMA wireless transmission in which the most distant receiver is identified, 
allowing a reduction in multipath interference and an associated reduction in transmitting 
power. 

A method of CDMA wireless transmission as claimed in claim 13, wherein said 
transmission is quadrature amplitude modulation. 
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